While developing an init that installs a system wide patch I needed a simple way to enable or disable it (forcing it to call the original patch) from the controlling application.
I found that the Gestalt manager could come in useful. In fact the procedure that installs a new selector, used in this case to check for the existence of the init, requires you to specify a response function which gets executed whenever the new selector is called. Being the function itself is part of the init, it is able to change the value of a status variable and return its state: assuming that the variable is a boolean. With two gestalt calls (max) it is possible to change the patch status. Follow some code fragments:
This tip may be a little obvious, I caught it right away, but some people may not have noticed the problem yet. Some people may have coded around it to begin with, but I didn't.
System 7.5 was the first time I saw the "Apple Menu Options" control panel. It is an extremely useful tool, I love it and use it constantly. But, there may be a slight difference in the way your application needs to handle menu highliting now that this control panel exists.
Here is the assumption I had been making for a long time: When the user selects a menu item, MenuSelect (and MenuKey) leave the menu title hilited. The application performs the indicated action and then unhilites the menu title. When no menu item is selected by the user (MenuSelect or MenuKey return 0L), the menu titles are not left hilited after the call.
The Apple Menu Options control panel is an exception. A menu selection in a submenu of the apple menu will leave the apple menu hilited, but MenuSelect will return 0L.
In the event handling code I have calls like this:
With this code, if the user selected an item in a submenu of the apple menu, the system will switch to the Finder and open the selected item (thanks to Apple Menu Options). When you switch back to your application, the apple menu will still be hilited (even if you call DrawMenuBar on the switch).
The work around is simple, call HiliteMenu( 0 ) even if MenuSelect returns 0L.
HandleMenuChoice should look like this:
void HandleMenuChoice( long menuChoice )
{
short menu;
short item;
if ( menuChoice != 0L ) {
menu = HiWord( menuChoice );
item = LoWord( menuChoice );
switch ( menu ) {
case mApple:
HandleAppleChoice( item );
break;
case mFile:
HandleFileChoice( item );
break;
// Other menus
}
// HiliteMenu( 0 ) was here
}
HiliteMenu( 0 ); // moved it to here
}
Your code may not look anything like this, but the idea is to call HiliteMenu( 0 ) even if MenuSelect returns 0L.
– Don Bresee
Los Angeles, CA
The Lost Paper
True story: I was once typing in some text in a word processor, when the computer suddenly crashed on me. I didn’t save a copy on to the hard-disk yet. I had to restart the computer and type it all over again. “But wait, the paper is still in the machine” I thought to myself. You see, when you restart all of the computer’s memory doesn’t get cleared, it just stays to what it was until it gets replaced with other information (usually, much like the behavior of a hard-disk). I had one thing going for me, I had MacsBug installed. Here are the steps I took to recover the paper:
First, I logged all of the work I was doing in MacsBug to a file. I did this using the “log” command. All you need to give the command is the name of the new file to log to. I named it “MyPaper” Good, now all of my MacsBug session will be on the hard-disk, so I can open it up with a normal text editor when I’m done.
Next, I needed to find where in memory my paper was. I did this using the “f” command. The first two parameters for this command is the range in memory in which you want MacsBug to search through. I wanted to search through all of my memory, which is 8 megs, so I typed in: “f 0 (400 * 400 * 8) “any string””. Where 0 is the beginning of memory and 8 megs is the top of it. The last parameter is the search string, balanced between two single quotes. I wanted to pick a distinct string, otherwise I would have hit other parts of memory that had it too, making the process take longer. I knew the word aardvark was mentioned in my paper, so I typed in this for the find command:
f 0 (400 * 400 * 8) “aardvark”
MacsBug then started searching for me. It came up with a small memory dump of something with the word arrdvark in it, but the words after it were not mine. (Which meant that I found another part of memory instead of my paper.) I then hit return to tell MacsBug to keep on searching. It then came up with a dump from my paper:
Searching for “aardvark” from 00000000 to 007FFFFF
Which was very good news indeed! This told me that the string “aardvark answer” could be found at address 00358200. (I got this address from the leftmost number given.)
Now that I knew where it was, the rest my task would be easy. I used MacsBug’s display memory ASCII command to show me what came after it, by typing in: “dma 00358200”. (You might not have this command, in which case you’ll have to use plain old dm, instead of dma.) I hit return until my paper was done being displayed.
Note: You can subract a number from the address to see what was before it. For instance, subracting #200 from an address will give you the address of the first byte of the 200 byte block before it.
I then typed in “log” again, which closed my log. I finally went out of MacsBug and opened the log file with SimpleText. Remember, the log had my whole session, not just the paper, so I had to delete the addresses and such from it, (which really isn’t that hard to do, if you know how to use your mouse and your delete key efficiently). The paper was saved.
Warning: In your search you might stumble upon MacsBug’s very own memory, with its own copy of your search string. To get out of this recursive loop, start the search over again with the base search address being outside of MacsBug’s memory.
